This invention relates to a system comprising a plurality of nodes.
Streaming framework software for media-processing typically defines standard interfaces for control and data transfers to and from media processors such as codecs, or pre/post-processors. As a result, (software instances of) media processors of various kinds can be controlled and connected by the framework in a uniform way. This makes software or hardware media processors components re-usable in different applications with widely varying streaming network graph topologies, which may dynamically change while running an application. Media processors that for their processing rely on using hardware accelerators or separate CPU/DSP cores also benefit from standard interfaces, because these standard interfaces then apply to the driver code and possibly standard hardware channels.
A typical media processing network contains vertices each consisting of a filter node, and edges forming the stream-connections between the filter nodes. A filter node usually consists of a media processor and a generic framework component that controls the media processor. Usually the filter nodes are executed each within their own OS-task (POSIX: thread). This has the advantage to allow the filtering node's media processor to operate actively: it may fetch its input data and deposit its output data in quantities as dynamically determined by the media processor (codec). Also it may periodically check for commands that may have been queued by some controlling entity, without interference in critical media processing steps.
An important disadvantage of streaming frameworks that assign one OS-task to each filter node is the relatively large task-switching overhead when filter nodes process small quantities of data or when the cycle requirements of the media processor is low (typical for pre- or post-processor pipelines). To suppress this overhead, it is common to introduce an amount of data queuing between filter nodes which will allow for less frequent task switching, but this introduces two new problems: excessive latency in the stream (more data is accumulated than needed for processing steps), and increased memory requirements.
More advanced streaming frameworks avoid the above described efficiency problem by assigning an OS-task only to a few (or only one) of the filter nodes. These nodes are called “active” while the other nodes are “passive”. A passive filter node has no own OS-task. Passive filter nodes are invoked and executed in the context of data production (push) or consumption (pull) of an adjacent filter node which is active, or which is passive and was itself called by another filter node. At least one active filter node must exist in such a streaming network.
However, these types of systems have further problems. For example, in an advanced streaming framework with passive filter nodes, the media processors need a different interface, depending on whether they are used in a passive, or in an active filter node. This means at least two versions of a media processor need to be written to provide its functionality at an arbitrary position in a streaming network.
Secondly, in the advanced streaming framework with passive filter nodes, the media processors in passive filter nodes are typically called with a producer-determined amount of input data (push), or a consumer determined amount of output space (pull). This may conflict with the needs of the media processor which may on the fly discover the amount of data needed/produced, depending on the contents of the stream.
It is therefore an object of the invention to improve upon the known art.